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UNITED STATES PATENT AND TRADEMARK OFFICE 



BEFORE THE BOARD OF PATENT APPEALS 
AND INTERFERENCES 



Ex parte LUDMILA CHERKASOVA, WENTING TANG, 
and SHARAD SINGHAL 



Appeal 2009-011665 
Application 10/801,793 
Technology Center 2400 



Before HOWARD B. BLANKENSHIP, JOHN A. JEFFERY, and 
ST. JOHN COURTENAY III, Administrative Patent Judges. 

JEFFERY, Administrative Patent Judge. 

DECISION ON APPEAL 
Appellants appeal under 35 U.S.C. § 134(a) from the Examiner's 
rejection of claims 1, 3-26, 28-32, 34-40, and 42-46. We have jurisdiction 
under 35 U.S.C. § 6(b). We affirm-in-part. 

STATEMENT OF THE CASE 
Appellants' invention evaluates a media server's capacity to support 
an expected workload in compliance with a service parameter. See 
generally Spec, ff 0007-12. Claim 1 is illustrative: 
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1. A method comprising: 

receiving, into a capacity planning system, workload 
information representing an expected workload of client 
accesses of streaming media files from a site; 

receiving, into said capacity planning system, at least one 
service parameter that defines a desired service characteristic to 
be provided by a media server configuration under the expected 
workload and defines a desired service characteristic to be 
provided by a media server configuration during periods of 
degraded service under the expected workload; and 

determining, by said capacity planning system, for at 
least one server configuration, how many servers of said at least 
one server configuration to be included at said site for 
supporting the expected workload in compliance with said at 
least one service parameter. 

The Examiner relies on the following as evidence of unpatentability: 

Huckins US 5,890,162 Mar. 30, 1999 

Eilam US 2004/0 1 1 1 509 A 1 June 1 0, 2004 

(filed Dec. 10, 2002) 

The Rejection 

The Examiner rejected claims 1, 3-26, 28-32, 34-40, and 42-46 under 
35 U.S.C. § 103(a) as unpatentable over Eilam and Huckins. Ans. 4-25. 1 



1 Throughout this opinion, we refer to (1) the Appeal Brief filed December 
12, 2008; (2) the Examiner's Answer mailed March 12, 2009; and (3) the 
Reply Brief filed May 11, 2009. 
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Contentions 

Regarding representative claim 1, the Examiner finds that Eilam 
discloses a capacity planning system with every recited feature except for 
streaming media files and a media server, but cites Huckins as teaching this 
feature in concluding the claim would have been obvious. Ans. 4-5. The 
Examiner also acknowledges that Eilam does not explicitly teach a service 
parameter that defines the service characteristic during periods of degraded 
service, but nonetheless contends that this degraded- service aspect is non- 
functional, and, in any event, is inherently subjective. Ans. 5-6, 27-28. 
These "subjective" conditions are said to be considered in view of Eilam' s 
accounting for conditions associated with weekdays and weekends, as well 
as long- and short-term conditions. Ans. 27-28. 

Appellants argue that the cited prior art does not teach or suggest a 
service parameter that defines a desired service characteristic during periods 
of degraded service as claimed. App. Br. 11-13; Reply Br. 2-3. Appellants 
emphasize that this limitation is functional since determining the number of 
servers to support the expected workload as claimed must comply with this 
parameter. Reply Br. 2-3. Appellants also argue various limitations of other 
claims which are summarized in the issue statement below. App. Br. 13-18; 
Reply Br. 4-7. The issues before us, then, are as follows: 

ISSUES 

Under § 103, has the Examiner erred by finding that Eilam and 
Huckins collectively would have taught or suggested: 

(1) a service parameter defining a desired service characteristic during 
periods of degraded service under expected workload as recited in claim 1? 
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(2) the service parameter specifying a limit on the amount of 
degradation of service encountered during periods of degraded service as 
recited in claim 3? 

(3) a performability parameter defining a service characteristic during 
non-compliant periods of operation as recited in claim 11? 

(4) a performability parameter defining a desired limit on the amount 
of continuous overload encountered by a server under the expected workload 
as recited in claim 22? 

(5) a performability parameter specifying a desired limit on 
degradation of quality of service during periods of degraded service as 
recited in claim 44? 

FINDINGS OF FACT (FF) 

1. Appellants' capacity planning tool "allowfs] for the service 
provider to specify service parameters that define limits as to the amount of 
service degradation experienced during "non-compliant" periods (periods 
during which the media server configuration is overloaded)." Spec, f 0033. 

2. Appellants' "Performability Parameters" "define limits on how 
'bad' the system performance may be during non-compliant time periods 
(e.g., during periods of performance degradation resulting, for example, 
from overload and/or node failure in a multi-node cluster system)." Id. 

3. "Performability Parameter(s) 104B define the type of service 
desired to be provided by the service provider during non-compliant periods 
(e.g., periods of degraded performance resulting, for example, from overload 
and/or failure of one or more nodes of a clustered media server, etc.)." Spec. 
f 0043. 
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4. Eilam's system dynamically allocates servers according to 
expected and current workload. To this end, traffic and workload are 
monitored continuously, and a Long-Term Forecasting Module (LTFM) 204 
analyzes associated logged data (load metrics 201) to generate a forecast of 
traffic and workload for the next day. These forecasts are then consolidated 
with customer contract information to generate a Resource Allocation Plan 
(RAP) for the next day to optimally assign servers to customers. Eilam, 
Abstract; ff 0001, 0020-21, 0032, 0035-37; Fig. 2. 

5. Eilam's long-term forecast (LTF) is based on the observation that 
there are seasonal patterns in Internet traffic, so that, for every customer, 
similar shapes of traffic are expected to repeat daily (possibly distinguishing 
between weekdays and weekends, or different days of the week, etc.). 
Eilam, <][0035. 

6. The LTF is provided to a Short-Term Forecasting Module (STFM) 
208 to refine the LTF for the next 10 to 20 minutes according to monitored 
metrics 201. Eilam, f 0035; Fig. 2. 

7. A bound or preset limit may be imposed on the number of servers 
that can be allocated to a single customer. Eilam, f 0071. 

8. Eilam discusses in connection with a known system in Figure 1 
that threshold events are generated according to the current load. Resource 
Manager 101 allocates or de-allocates servers according to these threshold 
values. Eilam, f 0034. 
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ANALYSIS 
Claims 1 and 4-10 

Based on the record before us, we find no error in the Examiner's 
obviousness rejection of representative claim 1 which calls for, in pertinent 
part, a service parameter defining a desired service characteristic during 
periods of degraded service under expected workload. Since the dispute 
before us hinges on whether Eilam teaches or suggests this limitation, and 
there is no dispute regarding the combinability of Eilam and Huckins, we 
therefore confine our discussion to Eilam. 

The Examiner apparently takes alternative positions in construing the 
disputed "degraded service" aspect of the recited service parameter noted 
above. On the one hand, the Examiner contends that this aspect is non- 
functional. Ans. 5-6. On the other hand, the Examiner indicates that 
"degraded service" is subjective, and Eilam accounts for such conditions at 
least in terms of distinguishing traffic conditions associated with weekdays 
and weekends, as well as long- and short-term conditions. Ans. 27-28. 

First, we agree with Appellants (Reply Br. 3) that the degraded 
service aspect of the recited service parameter is functional since it is used 
by the capacity planning system as a basis to determine the number of 
servers to include at a site to support the expected workload as claimed. 
Nevertheless, we see no error in the Examiner's alternative position that 
Eilam at least suggests the recited service parameter's degraded service 
aspect given the breadth of the term "degraded service." 

Notably, Appellants' Specification does not define "degraded 
service," but rather describes it in exemplary terms, namely in terms of 
overload and node failure in connection with "non- compliant" periods. See 
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FF 1-3. In this regard, Appellants indicate that "performability parameters" 
define the type of "service provided during non-compliant periods (e.g., 
periods of degraded performance resulting, for example, from overload 
and/or failure of one or more nodes of a clustered media server, etc.)" FF 3 
(emphases added). These emphasized exemplary and open-ended terms are 
telling, for they hardly limit a period of "degraded service" to these 
particular examples. 

Given this breadth, we therefore find no error in the Examiner' s 
position (Ans. 27-28) that Eilam's distinguishing daily traffic "shapes" 
between weekdays and weekends at least suggests that respective service 
levels would be different between these periods given their disparate traffic 
patterns and volume. See FF 5. That is, a higher traffic volume (e.g., on a 
weekday) could result in a period of degraded service (e.g., slower speed) 
for an expected workload, at least with respect to the service provided for 
periods of lower traffic volume (e.g., weekends). We therefore see no 
reason why this traffic-based distinction between particular days of the week 
would not at least suggest a period of "degraded service" under an expected 
workload, at least in a relative sense. 

We are therefore not persuaded that the Examiner erred in rejecting 
representative claim 1, and claims 4-10 not separately argued with 
particularity. 

Claim 3 

We will not, however, sustain the Examiner's rejection of claim 3 
which recites that the service parameter specifies a limit on the amount of 
degradation of service encountered during periods of degraded service. 
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Although Appellants do not squarely address the Examiner's reliance on 
Eilam's Paragraph 71 for this feature, 2 we fail to see — nor has the Examiner 
shown — how Eilam's limiting the number of servers to allocate to a 
customer (FF 7) specifies a limit on the amount of degradation of service 
encountered during such periods, let alone specifying this limit in the service 
parameter. The Examiner's brief reference to this limitation in the Response 
to Arguments section of the Answer (Ans. 28) simply does not explain how 
Eilam specifies limiting the amount of service degradation. Nor will we 
speculate in this regard here in the first instance on appeal. We are therefore 
persuaded that the Examiner erred in rejecting claim 3. 

Claims 11-21 

We will, however, sustain the Examiner's rejection of representative 
claim 1 1 which recites a performability parameter that defines a service 
characteristic during non-compliant periods of operation. This limitation is 
similar to claim 1 except for reciting a performability parameter and "non- 
compliant" periods of operation. Nevertheless, our analysis regarding claim 
1 applies equally here, particularly since the Specification indicates that 
periods of degraded performance are examples of non-compliant periods. 
FF 2-3. We are therefore not persuaded that the Examiner erred in rejecting 
representative claim 11, and claims 12-21 not separately argued with 
particularity. 



2 Compare App. Br. 13-14 (citing Eilam, f 0022) with Ans. 18 (citing Eilam, 
^0071). 
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Claims 22-26, 28-32, 34-40, 42, and 43 
We will not, however, sustain the Examiner's rejection of independent 
claim 22 which recites, in pertinent part, a performability parameter defining 
a desired limit on the amount of continuous overload encountered by a 
server under the expected workload. Although Eilam uses load metrics as a 
basis to construct a forecast (FF 4) and in determining threshold values in 
connection with the known system shown in Figure 1 (FF 8), we fail to 
see — nor has the Examiner shown — how Eilam 's forecast determination of 
Figure 2 involves a parameter that specifies a limit on the amount of 
continuous overload encountered by a media server configuration as claimed 
as Appellants indicate. App. Br. 15-16. Nor will we speculate in this regard 
here in the first instance on appeal. 

We are therefore persuaded that the Examiner erred in rejecting 
independent claim 22; (2) independent claims 30 and 36 which recite 
commensurate limitations; and (3) dependent claims 23-26, 28, 29, 31, 32, 
34, 35, 37-40, 42, and 43 for similar reasons. 

Claims 44-46 

We likewise reverse the Examiner's rejection of independent claim 44 
which recites, in pertinent part, a performability parameter specifying a 
desired limit on degradation of quality of service during periods of degraded 
service. As noted previously, we fail to see — nor has the Examiner shown — 
how Eilam' s forecasting and server allocation technique (FF 4-7) specifies a 
desired limit on degradation of service quality during periods of degraded 
service. The Examiner's reference to various passages in Eilam as allegedly 
teaching this feature (Ans. 17) is unavailing, for the Examiner does not 
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explain how a particular limit on service quality degradation is determined, 
let alone specified in performability parameters as claimed. Nor will we 
speculate in this regard here in the first instance on appeal. 

We are therefore persuaded that the Examiner erred in rejecting 
independent claim 44, and dependent claims 45 and 46 for similar reasons. 

CONCLUSION 

Under § 103, the Examiner did not err in rejecting claims 1 and 4-21, 
but erred in rejecting claims 3, 22-26, 28-32, 34-40, and 42-46. 

ORDER 

The Examiner's decision rejecting claims 1, 3-26, 28-32, 34-40, and 
42-46 is affirmed-in-part. 

No time period for taking any subsequent action in connection with 
this appeal may be extended under 37 C.F.R. § 1.136(a)(l)(iv). 



AFFIRMED-IN-PART 



Pgc 



10 



